Smartcards are well known in the art. The typical smartcard is dimensioned similarly to a credit card and can be fitted easily into a wallet. A contactless smartcard (CSC) differs from the traditional ‘contact’ credit card in that it includes a processor and memory embedded thereon and also includes a radio transponder so as to enable radio frequency (RF) communication between the smartcard and a smartcard terminal. The provision of the processor provides for more functionality and greater security on the card than are traditionally available on for example a magnetic stripe type credit card.
With the development of smartcards, many applications commensurate with the available functionality of the smartcard have also developed. Examples include security access cards, personal identification cards and recently the use of such cards in the transport arena where they are being used to replace the traditional magnetic stripe card ticket.
Advantages of the use of the smartcard, and particularly the CSC, as a ticket include the fact that the smartcard can process a transaction and update the date stored on the CSC much quicker than traditional cards (of the order of about 300 milli seconds) and as such its use improves the convenience and speed of access to transport by reducing the multiple seconds it otherwise takes to insert a ticket into a validating machine. Furthermore, since it is possible to identify the user, it is also possible to cancel the card in case of theft or loss. Further benefits include the facility to “reload” the ticket with value. Such advantages are leading to progressively more transport agencies around the world turning to smartcards for their ticketing.
In such ticketing arenas the user is provided with a smartcard ticket and on entry to the transport system, for example a Metro or Bus system, the card is read by a smartcard terminal, embodying many of the elements described in the following: An example of this arrangement is shown in FIG. 1. In this arrangement the user presents his CSC (100) at the bus for example. The card transmits the information relating to the card via an RF antenna (105) that is coupled via a hard-wired connection, such as for example a RS232 connection, to a Card Acceptance Device (CAD) (110). The CAD (110) includes a RF translator (110a) and a card driver module (110b). The information read by the CAD is then transferred on to a CSC terminal (115) where the processing of the information received from the CSC is conducted. The traditional model of CSC Terminal to CSC interaction involves the CSC Terminal connecting directly to a generic ISO-14443 Card Acceptance Device (CAD). The CSC Terminal is thus required to address the CSC at the ‘driver’ level: The smartcard terminal interfaces with the card using the low-level commands specific to the chosen smartcard technology, and is required to understand and manage the detailed file and data structures maintained on the card. This process requires the CSC Terminal to manage all of the hardware peripherals of the terminal (eg. screen, keyboard, LEDs, buzzer, gate-tripod or gate-flap, coin-mechanism, note-mechanism) as well as manage the CSC interaction, which includes: determine which type of card has been presented, perform the validation of the usability of the CSC, process the CSC data, update the CSC and report the transaction to a higher-tier computer, usually at periodic intervals such as when the bus returns to the depot. Moreover, each different manufacturer who supplies equipment to a transport system would, ideally, ensure that his CSC terminals process the various types of CSC in the same fashion as the CSC terminals of all other manufacturers supplying equipment to the system, in order that the user experience is common across the entire system. However, this is rarely achieved.
Additionally, where transport systems are operating in close proximity to each other (eg. near county or country borders), or in other situations which there is a political or commercial will to achieve ‘interoperability’, it is known for a specific transport provider, i.e. the transport provider with the license to operate in that geographic region, to roll out a system using the standard developed by one manufacturer and for a second transport provider to roll out a system using a second standard as provided by the manufacturer chosen for that implementation. In most cases, the standard developed by one provider does not conform to that developed by the second provider and as such it is not a trivial exercise to provide a ticketing solution that enables use of multiple transport solutions, or to provide a solution that crosses geographic borders. Developments towards solving this problem have led to the publication of generic transport communication language standards (for example (IOPTA). However, because there is no world-wide standards body which holds jurisdiction in all countries of the world, there are now a proliferation of these so called ‘standards’ across Europe, Asia and America. Furthermore, because the committees which provide these standards are often manned by representatives of the terminal manufacturers, and because of the multiplicity of card-types available, the standards tend to focus on the low-level CSC-Terminal-to-card interface and do not provide any generic business-level interface facility.
The advantages of providing an integrated transport system have been recognized in numbers of countries. For example, in another known standardization effort in the United Kingdom, public transport executives, bus operators and the franchisees of the UK Rail Network came together in 1998 to form the Integrated Transport Smartcard Organisation (ITSO) which had at its core the development of a multi-modal smart card based transport initiative. ITSO's efforts in providing a solution to the problem of interoperability included the publication of yet another ‘standard’ and the development of an ITSO-specific Security Access Module (SAM). The ITSO SAM was aimed at providing a common mechanism, through which, (i) the authenticity and integrity of ITSO-compliant CSCs could be validated, and (ii) the communication of the CSC transactions to higher-tier computers could be achieved with integrity. However, ITSO was simply another in the multiplicity of published ‘standards’ and the ITSO SAM has, at this time, not delivered an interoperable solution across multiple smartcard types.
There is therefore still a need to provide an integrated architecture that utilizes the benefits of contactless smart cards which (i) can be used, interoperably, across a variety of different CSC types and/or transport systems, (ii) provides a common user experience even in the presence of CSC terminals from different manufacturers, and (iii) elevates the interface to the CSC from the card level to a business level.